This invention relates to the field of logic simulation of electronic circuits. More specifically, this invention relates to methods and apparatus for selectively displaying signal values generated by a logic simulator.
Over the past several decades, computer performance has increased at an exponential rate. A primary reason for this dramatic increase in performance is the rapid advancement of integrated circuit technology. Each generation of integrated circuit technology can typically accommodate four times more circuitry than the previous generation. Because more circuitry can be provided on a single integrated circuit, fewer integrated circuits are required. Besides increasing the performance, circuit integration can reduce the size, power, and cost of such systems.
The design and test of these systems becomes more difficult, time consuming and tedious as system integration increases. One reason for this is that the number of input and/or output pins on an integrated circuit is typically limited, and yet the amount of circuitry on the integrated circuit is dramatically increased. Consequently, modem integrated circuits tend to have an ever increasing number of internal nets that are neither controllable nor observable from the input and/or output pins of the device. This can make testing and debugging such devices difficult.
One approach for increasing the testability of modern integrated circuits is to include built-in-self-test or the like into the design. One built-in-self-test approach involves replacing each of the registers in the design with scan type registers that can operate in both a functional mode (parallel) and in a test mode (serial scan mode). Each of the scan registers is connected to form one or more scan chains. For many built-in-self-test schemes, shadow registers are also provided at the input and output pins. This allows the input and output pins to be both controllable and observable via one or more scan chains.
To test the integrated circuit, the scan registers are put into a test mode, and a test vector is serially scanned into one or more of the scan chains. The scan registers are then put into a functional mode, and clocked once. When the scan registers are clocked, the test vector data passes from the original scan registers, through selected logic, and to receiving scan registers. The scan registers are then put back into the test mode, and the results are scanned out of the circuit and compared to an expected result. This is typically repeated with a number of different test vectors until an acceptable level of fault coverage is obtained.
A limitation of many built-in-self-test schemes is that significant overhead is required. This typically includes replacing each register within the design with a larger and more complex scan register. In addition, many built-in-self-test schemes require that the integrated circuit be in a test mode before a test vector can be scanned into the circuit. Thus, those errors that occur during functional operation are typically not detected and/or analyzed. Software errors or the like, which are traditionally detected and analyzed during functional operation of the device, are therefore not handled well by many built-in-self-test schemes. These limitations detract from the desirability of many built-in-self-test schemes.
To help analyze errors that occur during functional operation of a system, history stacks or the like have been incorporated into circuit designs. A history stack is a collection of xe2x80x9cnxe2x80x9d registers that store the previous xe2x80x9cnxe2x80x9d states of one or more nets in the design, where xe2x80x9cnxe2x80x9d is greater than or equal to one. When an error is detected, the historical data stored in the history stack can then be used to determine the cause of the error. History stacks may be particularly useful because the success of debugging many design problems is dependent on the knowledge of the sequence and type of events that occurred just prior to the unexpected logic behavior or error condition. The historical data stored in the history stacks can often provide this information.
A limitation of using a history stack approach is that significant overhead may be required. A history stack must typically be provided for each net in the design that may be deemed critical during later testing of the circuit. Since it is difficult to predict which nets within the design will be deemed critical for debugging an unexpected problem, circuit designer must typically provide many history stacks throughout the design. These history stacks can represent a significant overhead within the design.
Another limitation of using history stacks is that the proper xe2x80x9ccriticalxe2x80x9d nets within the design must be selected during the design phase. This is often problematic because the nets that would be helpful in debugging an unexpected logic behavior cannot be efficiently predicted during the design phase. Thus, it is often difficult to identify the xe2x80x9ccriticalxe2x80x9d nets within the design. If the proper critical nets are not identified correctly, historical data relating to a particular error may not be available, making it difficult to debug the error.
Another limitation is that history stacks are typically only useful in detecting errors in hardware that has already been built. It is costly to correct a logic design error after the hardware has been built. To correct just one integrated circuit, for example, at least one new mask must be made, and at least one lot of new wafers must be fabricated using the new mask. This can cost significant amounts of money, and often more importantly, significant amounts of time (e.g. schedule).
To reduce the chance of having a design error, extensive logic simulations are often performed. To perform the logic simulations, the circuit design is often modeled using a high-level behavior language such as the VHSIC (Very High Speed Integrated Circuits) Hardware Description Language (VHDL). Timing information may be included in the model.
Before executing a logic simulation, the circuit designer must typically specify one or more test vectors for forcing the inputs of the design. The circuit designer typically also identifies which of the nets within the design to observe during the simulation. This is typically accomplished by designating selected signals as being listed or traced. When a signal is designated as being traced, for example, the logic simulator may display the logic state of the signal versus time in a wave format. When a signal is designated as being listed, the logic simulator may display the logic state of the signal versus time in a tabular format, wherein each column in the table corresponds to a particular signal, and each row in the table represents a time.
Some logic simulators allow the user to select when to provide an updated listing of the identified signals. For example, some logic simulators have two modes for updating the identified signals. One mode is to list on xe2x80x9cintervalxe2x80x9d and the other mode is to list on xe2x80x9cchangexe2x80x9d. In a list on interval mode, the simulator typically updates the signal values of all listed signals at a specified time interval. The specified time interval is often set to correspond to, for example, the expected clock period of the circuit design. Conversely, the list on change mode typically updates the signal values of all listed signals whenever any of the listed signals changes state. The list on change mode typically provides a longer output than the list on interval mode, at least when timing delays through non-register circuitry is simulated.
Since many circuit designs have a large number of nets, logic simulators typically only store a historical record for those signals that are identified as being listed or traced. Historical data regarding those signals that are not identified as being listed or traced are typically not stored. Since it is difficult to determine in advance which signals will be of interest when debugging an unexpected problem, circuit designers typically designate a large number of signals to be listed or traced. Accordingly, the output listing or trace window of many logic simulation runs is large, particularly when entire systems or subsystems are simulated over a number of clock periods. Sifting through these large output listings or trace windows to find selected signals and/or events can be difficult, time consuming and tedious.
Therefore, it would be desirable to provide a method and apparatus for displaying only those signal values that are relevant to particular problem and/or that fall within a relevant time period. Also, it may be desirable if the signal values are displayed in a manner chosen by the user. This may help the circuit designer efficiently obtain the relevant signal values; thereby potentially reducing the time required to debug a particular problem.
The present invention overcomes many of the disadvantages of the prior art by providing a method and apparatus for selectively displaying signal values generated by a logic simulator. Preferably, only those signal values that are relevant to a particular problem are displayed. This may reduce the need to sift through large output listings and/or trace windows to identify the relevant information.
In accordance with one embodiment of the present invention, a data processing system is provided that is suitably programmed to identify the time at which one or more of selected signal values are in a predetermined state. The selected signals are preferably those signals that are listed or traced by the logic simulator, and are a subset of all of the signals in the circuit design. The data processing system further preferably displays the signal values of a predetermined set of signals that correspond to a time that is related to the identified time. The predetermined set of signals is preferably a subset of the selected signals. The predetermined set of signals may be displayed on an electronically controlled screen, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), or may be printed on a fixed medium, such as paper.
The present invention contemplates any number of methods for identifying the time at which one or more of the selected signals are in a predetermined state. One illustrative method includes identifying when one or more of the selected signals are in a particular logic state (e.g. logic 1). Another illustrative method includes performing one or more logical operations using the signal values of one or more of the selected signals. For example, an xe2x80x9cANDxe2x80x9d operation of two of the selected signals may be performed, and the signal values associated with the predetermined set of signals may be displayed if the AND operation yields a logic 1. Any logical operation or combination thereof involving one or more of the selected signals is contemplated. In addition, logical operations including those involving if-then statements and other conventional programming statements are also contemplated.
The logic simulator is preferably an application program having a simulation kernel, wherein the primary responsibility of the simulation kernel is to perform the logic simulation and generate the resulting signal values. It is contemplated that the logic simulator itself may identify the time at which one or more of the selected signal values are in a predetermined state. The logic simulator may also display the signal values of the predetermined set of signals that correspond to a time that is related to the identified time. Preferably, the logic simulator application program includes sub-routines and/or functions that are separate from the simulation kernel for identifying and displaying the appropriate signal values.
Attentively, or in addition to, it is contemplated that the identifying and displaying functions may be performed by a post-processing program that is separate from the logic simulator application program. In this embodiment, the logic simulator preferably includes a storing function for storing the selected signal values to one or more files. Normally, this is accomplished by storing a listing of the selected signals, as described above. A post-processing program may then extract the appropriate signal values from the listing and display the results. Preferably, the post-processing program performs at least one of the following actions selecting one or more of the selected signal values; combining one or more of the selected signal values; classifying one or more of the selected signal values; grouping one or more of the selected signal values; arranging one or more of the selected signal values; and formatting one or more of the selected signal values.
Preferably, the post-processing program emulates a history stack. Unlike hardware history stacks, however, the history stacks of the present invention are xe2x80x9cvirtualxe2x80x9d history stacks in that they are not incorporated into the hardware design. That is, the virtual history stacks of the present invention are only implemented in the simulation domain, and not in the hardware domain.
The post-processing program. may emulate a number of virtual history stacks, wherein each virtual history stack identifies and stores signal values that are associated with a particular event or part of the system. When it is desirable to examine the signals associated with a particular event or part of the system, a corresponding virtual history stack is selected and executed. The selected virtual history stack preferably processes the output provided by the logic simulator, and displays only the desired signals associated with the event or part of the system.
Like hardware history stacks, the xe2x80x9cvirtual history stacksxe2x80x9d of the present invention can display the previous xe2x80x9cnxe2x80x9d states of the corresponding signals, where xe2x80x9cnxe2x80x9d is user definable. However, unlike hardware history stacks, the xe2x80x9cvirtual history stacksxe2x80x9d can grow to very large sizes, dependent only on the length of time simulated and the size that a logic simulator output file is allowed to reach. The xe2x80x9cvirtual history stacksxe2x80x9d can also post states, if desired by the user, e.g. to observe the behavior after an identified condition was reached. As indicated above, history stacks in general may be particularly useful because the success of debugging many design problems is dependent on the knowledge of the sequence and type of events that occurred just prior to the unexpected logic behavior or error condition. The historical data stored in the virtual history stacks can often provide this information.